Safe output protocol for files to multiple destinations with integrity check

ABSTRACT

Protocol is provided for safe transfer of files from between nodes of a communication system. The protocol includes a handshake operation between a source (local or initiating) node sending one or more files and a remote (responding) node receiving the files to ensure that control of the file remains with the source node until the file is successfully transferred. The protocol is provided by a file transfer manager that controls the transfer process through a series of file moves that include moving the file into a directory associated with the file transfer manager, from which the file is sent and moving the file out of that directory after the remote node acknowledges a safe copy operation of the file. Files are maintained in the sending directory and under control of the source node at least for a configurable amount of time until the file is safely transferred. Files can be retrieved by the remote node after they have been transmitted for a configurable amount of time, after which they will be deleted from the local node.

RELATED APPLICATIONS

This application claims benefit of priority from U.S. ProvisionalApplication No. 60/299,475, filed on Jun. 21, 2001, the entiredisclosure of which is expressly incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a protocol for reliable transfer ofinformation in a communications network, and in particular, to areliable output protocol for sending files from one node to one or moreother nodes in a network.

2. Description of the Related Art

The brisk pace of development in fixed and wireless telecommunicationsnetworks has led to an ever-increasing scope of service andbusiness-support functions supported by these networks. These functionsusually require an exchange of information that is tied with value, suchas a generated revenue value or any other value deemed critical to abusiness, government or personal entity. Examples of valuableinformation exchanged between computer systems include, for example,charging data transferred from a telephone switch to a billing system,fund transfers, tax filings, credit reporting, financial reportingbetween offices and statistics from the telephony or radio parts of anetwork that must be collected to optimize network efficiency.

Many new and innovative subscriber services require complex chargingschemes. In one new service, “virtual” operators are willing to pay forthe right to use telecom equipment owned by other operators. Networkoperators of these services are demanding fast, almost instant billing(such as with prepaid cards), in which charging data must be processedand made accessible in real-time or near real-time. Real time ornear-real time processing of files is also desired in network systemsproviding detection of fraud, hot billing, subscriber analysis orsubscriber crediting services.

At the same time, the implementation of more and more applications onlarge numbers of small machines has led to an increase in movement ofdata between business computer systems. Much of this data exchange isperformed using file transfer software embedded within business softwareapplications running on these computers. Software designers are oftenrequired to include specific interfaces to the file-transfer software intheir programs. In addition, these programs frequently deal with matterssuch as error-analysis, recovery, routing, and receipting, which aremore appropriate to communications software than to businessapplications.

Network operators are finding themselves increasingly burdened as thevolume of information switched over their network nodes continues togrow. To cope with rapidly increasing data-processing loads relating tocall-charging, and the demand for real-time or near real timeaccessibility of this data, network operators are increasinglyoffloading capacity-demanding tasks to external computing systems forsubsequent processing. These external systems are generally openstandard (e.g., transfer control protocol/Internet protocol (TCP/IP) andopen systems interconnect wide area network (OSI-WAN)).

It is imperative that the data not be corrupted, lost or duplicated whenvaluable information is sent from a source to a destination in atelecommunications network. In the case of charging data from atelephony switch to a billing system, for example, data-loss would implyloss of revenue because subscribers cannot be billed for their telephonyusage. On the other hand, data-duplication would imply over-billing ofsubscribers, which could result in subscribers leaving the operator, badpublicity, and thus loss in revenue. It is therefore vital that thecharging information be transported in a reliable, safe way and thatcontrol over the information is either at the sending or receiving end(e.g., at a telephony switch or at a billing system). A systemtransferring valuable data should also have the ability to cope withsituations involving problems with the communications link (e.g., whenthe link is broken) or with any of the two nodes involved (e.g., systemcrash/restart).

Several things may go wrong as soon as an information file is at andunder control of a receiving end device (e.g., a billing systemcomputer) even when one or more files are transferred intact from alocal node to a remote node. For example, data can be corrupted duringstorage of the file on disk or during the process of copying it, whichwill ultimately result in revenue loss for the operator.

Thus, there remains a need in the art for a file output protocol thatsafely and reliably transfers files from one network node to one or moreother network nodes without loss or duplication of the files and alsoinsures that files that have been transferred remain accessible forretransmission.

SUMMARY

Accordingly, the present invention is directed to safe output protocolfor files to multiple destinations with integrity check thatsubstantially obviates one or more of the problems due to thelimitations and disadvantages of the related art.

In one aspect of the present invention, an output protocol in acommunication system includes a handshake between a local node and aremote note to specify when a file is under the control of the localnode and when it is under the control of the remote node.

Additional aspects and advantages of the invention will be set forth inthe description that follows, and in part will be apparent from thedescription, or may be learned from practice of the invention. Theaspects and advantages of the invention will be realized and attained bythe system and method particularly pointed out in the writtendescription and claims hereof as well as the appended drawings.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and exemplary only andare not restrictive of the invention, as claimed.

It should be emphasized that the terms “comprises” and “comprising,”when used in this specification, are taken to specify the presence ofstated features, integers, steps or components; but the use of theseterms does not preclude the presence or addition of one or more otherfeatures, integers, steps, components or groups thereof

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the invention and are incorporated in and constitute apart of this specification, illustrate embodiments of the invention thattogether with the description serve to explain the principles of theinvention. In the drawings:

FIG. 1 is a block diagram of a computer at a source node and threeremote node computers in a communications network.

FIG. 2 shows the hardware components of the computers shown on FIG. 1.

FIG. 3 shows an exemplary protocol stack in accordance the presentinvention.

FIG. 4 is a block diagram showing an exemplary relationship between afile transfer manager using output protocol in accordance with a firstembodiment of the present invention and computer components at a sourcenode.

FIG. 5 a shows an exemplary directory structure associated with outputprotocol of the first embodiment of the invention.

FIGS. 5 b-5 g are illustrative of exemplary file movement processeswithin the directory shown in FIG. 5 a that are provided by outputprotocol of the first embodiment.

FIG. 6 is a graph illustrating an exemplary file transfer processprovided by output protocol of the first embodiment of the presentinvention.

FIG. 7 is a block diagram of an exemplary formatting and outputsubsystem (FOS) utilizing a output protocol in accordance with a secondembodiment of the present invention.

FIG. 8 shows an exemplary protocol stack of a source node computer thatmay be used in the system of FIG. 7.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

FIG. 1 shows a communications network that includes a computer at asource node 100 from which files are transferred along any one ofcommunication paths 101-103 to a corresponding computer at networkdestination nodes 110-130. While three destination nodes are shown, itis to be understood that the number of destination nodes may be anynumber, including one. Communication paths 101-103 are shown insimplified form as direct communication paths between node 100 and nodes110-130, however, each of the communication paths 101-103 may include acombination of fixed and/or wireless communication links establishedbetween numerous intervening nodes from source node 100 and destinationnodes 110-130. It is to be understood that the designation “source”(“local”) or “destination” (“remote”) depends on the reference pointwhere an outgoing file transfer originates. For example, any one ofcomputers at nodes 110-130 also may be sending one or more files to thecomputer at node 110. In this case, location of one of the nodes 110-130sending one or more files is considered to be at the source (local) nodeand the location of the node 110 is considered to be at the destination(remote) node.

FIG. 2 shows the main hardware components of each of the computers atnodes 100-130. These hardware components include a central processingunit (CPU) 210, a memory 220, and an input/output (I/O) port 230. Alsoshown are peripheral components that may be included in each computer100-130. These peripheral devices include a display device 240, aprinter 250, and a keyboard 260. Each of components 210-260 is shownconnected together by a bus 270. The I/O port 230 is used to connect thecomputer to a communication link, such as one of communication paths101-103. The computer memory 220 includes software comprising one ormore active or inactive application programs that run on the computer.These application programs can be related, working together, or they canbe performing their own independent activities. As explained below indetail, at least the computer at source node 100 includes outputprotocol that utilizes the normal file system of the computer at sourcenode 100 to process files for transfer to one or more of the othercomputers at destination nodes 110-130.

With reference to FIG. 3, there is shown layered communicationarchitecture (a protocol stack) 300 of the computer at the source node100. Protocol stack 300 comprises application layer 310 that includesone or more software applications for performing tasks pertinent to theparticular mission of a business unit, organization, person or otherentity utilizing the computer. At least one of these applications hasaccess to files that are stored in the computer memory 220 and mayfunction to move and/or copy the files within the directories of thememory 220, as well as initiate sending one or more of the files in thememory to a computer at a remote node. Associated with the applicationlayer is a file transfer manager 320. File transfer manager 320 usesoutput protocol in accordance with the present invention, describedlater in detail, that controls the transfer of one or more files andmessages between source and remote nodes. The output protocol used byfile transfer manager 320 may be performed by software resident to atleast one or more applications running on the computer at the sourcenode or provided in a separate software program accessible by any one ofthese applications. When an application running on the computerinitiates a transfer of one or more files, the file transfer manager 320is responsible for controlling the transfer based on output protocolthat controls a sequence of events.

Network interface layers 330 allow communication between various systemsand/or applications running on a computer network. The output protocolused by file transfer manager 320 is an intermediate layer in theprotocol stack 300 that communicates with both the application layer andthe interface layers 330. Interface layers 330 include the high levelfile transfer protocols necessary to specify the contents of the fileand its properties and lower level protocols at which the data istransmitted in individual bytes of data between the source node computerand the destination computers. For example, communication architecture300 may be based on an Open Systems Interconnection (OSI) referencemodel that includes the file transfer, access, and management (FTAM)protocol, or the file transfer protocol (FTP) of the Internet standard.Data transmitted at the lower level protocols may use either local areanetwork (LAN) or wide area network (WAN) protocols. For example,transfer control protocol/Internet protocol (TCP/IP) and Ethernet-enableLAN-type communication may be used in local and large networks, and X.25(OSI-WAN standard) protocols may be used in a WAN. X.25 is the ITU-Trecommendation for the interface between data terminal equipment (DTE)and data circuit-terminating equipment (DCE) for terminals operating inthe packet mode and connected to public data networks by dedicatedcircuit. Of course, other industry-standard data transmission protocolsmay be used in the present invention, for example, Token Ring, ATM,SONET, and Frame Relay.

FIG. 4 shows a generalized diagram of a system 400 including acommunication protocol based on protocol 300 of FIG. 3 utilizing outputprotocol in accordance with a first exemplary embodiment of the presentinvention. The present embodiment uses a file system resident to,associated with, or used by one or more applications running on acomputer to facilitate safe transfer of one or more files stored on thatcomputer to at least one other computer in a communications network.System 400 is included in at least a computer at a source node, however,both the source node computer and a remote (destination) node computermay comprise system 400. As shown in FIG. 4, system 400 includes anynumber, n, of active or inactive applications 4101-410n that can berelated, working together, or working independently from one another. Atleast one of the applications 4101-410n has access to a file store 420where files of the computer file system are stored. System 400 alsoincludes a file transfer manager 430 that uses an output protocol,described later in detail, to provide safe and reliable transfer of oneor more files between the source node and the remote node(s). The filetransfer manager 430 has access to and control over a number ofdirectories in the file store 420. These directories also may beaccessible by at least one of the applications 4101-410n.

When one of the applications 4101-410n on the source computer wishes tosend one or more files to a remote (destination) node computer, thefile(s) intended for transfer are moved or copied to a directory in thefile store 420 associated with the file transfer manager 430. Forexample, an application wishing to send a file to a remote node computermay move one or more files to an “initial” directory associated with thefile transfer manager 430, which periodically scans the initialdirectory to detect the presence of files waiting to be transferred.Alternatively, a file transfer program 430 may be running in thebackground of an operating environment of a source node computer and maywork in conjunction with at least one application program on the sourcenode computer when the application wants to send one or more files to aremote node. The system 400 also may process an outgoing transfer offiles from the source node computer by way of a request from a remotenode computer. The file transfer manager also may include or has accessto a calendar function (not shown) that initiates a file transfer fromthe file store 420 at predetermined intervals of time.

Thus, an outgoing transfer of one or more files from a computer at asource node may be accomplished by an explicit call to the file transfermanager 430 to initiate a file transfer by an application running on thesource node computer or a request by a remote node computer to fetch afile (or files) from the source node computer, or by the file transfermanager itself detecting a file during a periodic scan of its initialdirectory (to which an application wanting to transfer a file forwardsthe file). In any case, if one or more files intended for outgoingtransfer are forwarded to the initial directory associated with the filetransfer manager 430, a series of processes including moving the filebetween directories at the source node is performed before and after thefile communicates with protocol layers of the network interface layers330. The series of processes additionally include exchanging controlover the transferred file to the remote node computer by renaming thetransferred file at the remote node after the file has been moved fromthe directory from which files are sent by the source node computer.

Based on the foregoing, the operating system of at least the source nodecomputer should support directories, and file rename or move operationsshould be atomic. The system 400 is independent of the operating systemof the remote node computer, which may be a Windows Nt™, Windows 2000™,Windows 98™, Windows 95™, Novell NOS, Tandem™, Novell™, OS/390™,AS/400™, Open VMS, MVS, or UNIX™ operating system, for example. Thesystem 400 of the present invention obtains a benefit of usingindustry-standard platforms in that the system 400 may connect withanything from a PC to a mainframe computer.

Exemplary processes performed by the output protocol will now bedescribed with reference to FIGS. 5 a-5 g. As shown in FIG. 5 a, theoutput protocol may utilize a directory structure 500 that includes thefollowing directories:

TmpReady. This directory contains files that are being created, but notyet ready for transmission. Directory TmpReady may comprise the“initial” directory associated with the file transfer manager 430,described above.

Ready. This directory contains the files that are ready to be sent.

Send.<ID>. This is a series of directories, one for each remote node,that contains the files that are currently being sent to those remotenodes.

Delete. This directory contains files that have been recentlysuccessfully sent to a remote node.

Keep. This directory contains all the files that have been successfullysent. They remain here until a predefined time period has elapsed or thedisk of the local node runs out of disk space.

The names of the files to be transported are flexible. For example, inthe case systems transferring charging data the names of the files maybe constructed of the dynamically variable terms listed in the Table.

TABLE 4 digit year 2 digit year 2 digit month 2 digit day 2 digit hours2 digit minutes 2 digit seconds 4 digit transient (reset to zero atsystem restart) sequence number without leading zeros 4 digit transient(reset to zero at system restart) sequence number with leading zeros 4digit persistent (never reset to zero) sequence number without leadingzeros 4 digit persistent (never reset to zero) sequence number withleading zeros A constant string Cyclic Redundancy Check (CRC), used forintegrity check on the file Exchange (or node) name

With reference to FIG. 5 b, when an application on the computer at asource node wishes to send file(s) to a computer at a remote(destination) node the source node computer creates and saves thefile(s) in the TmpReady directory. In FIG. 5 c, the file created andsaved in the TmpReady directory is moved to the Ready directory once thefile is ready for transmission. As shown in FIG. 5 d, once the localnode wants to send a file or the remote node wants to fetch a file, oneor more files are moved from the Ready to the Send.<ID> directory. WhileFIGS. 5 a-5 g show a single directory “Send” for the Send.<ID>directories, the Send directory may actually comprise series ofdirectories, for example, Remote1, Remote2, etc., for storing one ormore files for transfer to respective ones of a plurality of remotenodes. In FIG. 5 e, files in the Send.<ID> directories are sent, one byone, to the remote node where they are stored with the same name in areceiving directory of the remote computer, but with a “.tmp” extension.As long as this remote file has this “.tmp” extension, control over thisfile is still at the local node such that the remote node is not allowedto handle the file. When the sending of one file from the Send.<ID>directory is complete, the file is moved from the Send.<ID> directory tothe Delete directory, as shown in FIG. 5 f. After the file is moved tothe Delete directory, the computer at the source node sends a message tothe computer at the destination node which instructs the computer at thedestination node to remove the “.tmp” extension of the transmitted fileor rename the file without the “.tmp” extension. As soon as the “.tmp”extension is removed, the system at the remote node assumes control overthe transmitted file.

If more files are remaining in the Send.<ID> directory, then processesshown in FIGS. 5 e to 5 g are repeated. If there are more files in theReady directory to send, then the processes shown in FIGS. 5 d to 5 gare repeated with an additional repetition of the processes of FIGS. 5 eto 5 g for each file moved to the Send.<ID> directory from the Readydirectory. The Delete directory is on regular intervals scanned for newfiles that have occurred here. If files are found, they are moved to theKeep directory. This is done to prevent overhead from becomingincreasingly large when scanning a directory which may contain thousandsof files. If files are in the Keep directory for the specified time orwhen a disk allocation threshold is met or exceeded, they are removed.

The output protocol of the present embodiment is efficient in that itrequires minimal system resources for its support. This is because afile system used by the output protocol is already resident to and usedby a system and a minimal amount of software is required to implementthe protocol. The output protocol also is independent of the underlyingfile transfer protocol (e.g., FTP or FTAM) or network architecture(e.g., TCP/IP and OSI-WAN).

FIG. 6 is a graph showing an exemplary sequence of events used in theprotocol of the present embodiment when transferring a file from asource node computer to a remote node computer. For example, thesequence of events of FIG. 6 may occur during processes shown in FIGS. 5d and 5 e. As shown in FIG. 6, after the one or more files in the Readydirectory are moved to the Send.<ID> directory, the source node computersends a request message 610 to the remote node computer requesting afile transfer. At the same time, a timer may be started. The requestmessage includes an identifier for the transfer and details of the filesthat it wishes to send. The identifier may contain the name associatedwith the source node and/or a serial number of the transfer. The detailsof the files may be expressed as parameters that define the type of filethat the source node wishes to transmit, such as a list of thefilenames, the date of creation of the file and/or the size of thefiles, for example. If the remote node computer successfully receivesthe message and may receive the transmitted file(s), it sends anacknowledge message 612 to the source node computer.

If the source node fails to receive an acknowledge message before thetimer expires, the source node repeats the request message 610 andrestarts the timer. A failure by the source node computer to acknowledgethe request for a predetermined number of attempts generates an alarmmessage. A timer may be similarly utilized with any request message madeat the source node to ensure that the remote node computer is ready toreceive messages or files transferred from the source node. When theacknowledge message 612 is received, the source node computer generatesand sends a message 614 to the remote node computer requesting that theremote computer create and open a new file using the filename of thefile, but adding a “.tmp” extension to the filename, for example“filename1.tmp,” for a transferred file named “filename1.” If the remotenode has successfully created and opened the file filename1.tmp, itresponds by sending an acknowledgment message 616 to the source node.

The source node then sends a request 618 to write filename1.tmp to thereceiving directory of the remote node. If the request 618 issuccessfully received, the remote node responds by sending a writeacknowledge message 620 to the source node. After the write acknowledgemessage 620 is received at the source node, the source node computerthen proceeds to push the file (i.e., filename1.tmp) to the remote nodecomputer in a data copy request message 622. The file may be copied tothe remote node using a lower level file transfer protocol, for example,FTP or FTAM.

The data copy request message 622 may include an integrity check, suchas an error check of the received data. For example, cyclical redundancycheck (CRC) bits may be included in the header of the data copy requestmessage 622 to check the integrity of the transferred file. The remotenode computer recognizes the end of file condition of the transmittedfile checks whether the CRC matches the running CRC total that is beingkept on the file. If the CRC check is successful, the remote noderesponds by sending a data copy acknowledgment message 624 to the sourcenode computer. It is to be understood an integrity check scheme otherthan CRC known to those skilled in the art may be used in the presentembodiment to detect unsuccessful data transfers. If an integrity checkfails, the remote node computer may request a retransmission of the filefrom the source node computer for a predetermined amount of time, afterwhich the file is deleted from the local node.

After the source node receives the acknowledgment from the remote nodethat the file has been successfully copied, the file filename1.tmp inthe Send directory of the source node is moved to the Delete directory,as shown in FIG. 5 e. Once the file is moved to the Delete directory,the output protocol directs the source computer to send a message 626 tothe remote node computer requesting an “end file transfer-remove ‘.tmp’extension” (of the transferred file filename). The remote node computerresponds by sending an acknowledge message 628 to the source nodecomputer if the previous message 626 was successful (i.e., that the filewas copied error free and the “.tmp” extension was removed at the remotenode). At this point, control of the file transferred from the sourcenode computer has shifted to the remote node computer. If more filesremain in the Send directory, the sequence of processes shown in FIG. 6is repeated for each file (one at a time). The order of selection by theoutput protocol of files for transfer from the Send directory ispreferably the order that the files were created in the TmpReadydirectory (at least in the initiating mode).

The handshake operation performed by the above-described protocolexactly specifies when a file is under control of the source node andwhen it is under the control of the remote node. This added handshakeduring a file transfer between the source node and the remote node(s)prevents loss or duplication of data, which might otherwise arise fromrace conditions present when a file remains in an outbound directory andexclusive control of the file is not specified. Loss or duplication offiles is also prevented in instances where disconnect problems occur ateither the source node or the remote node (e.g., a broken communicationlink or during a system crash/restart) because control of the file isnot shifted until the remote node acknowledges safe transfer of thefile, i.e., the file will remain available for retransmission in theoutbound directory (e.g., the Send directory) until receipt of asuccessful transfer acknowledgment from the remote node. The filetransfer manager of the present embodiment also allows the remote nodeto retrieve files for a predetermined time from the source node in caseswhere the file has been safely transferred by the source node, but isthereafter corrupted at the remote node (e.g., during storage of thetransferred file on disk). In such a case, the remote node may send amessage to the source (local) node requesting retransmission of a filethat the source node previously relinquished control thereof. Becausethe file is maintained in the Delete or Keep directories for aconfigurable amount of time, the file manager may efficiently scan thesedirectories for the requested file and move the file from the Delete orKeep directories to the Send directory for retransmission.

Multiple remote nodes (destinations) may be supported by the presentembodiment, but the file(s) will only be sent to exactly one destinationat a time. A file(s) or message(s) transferred to multiple destinationsmay be made by utilizing any file transfer protocol available in thenetwork interface layers, preferably by way of an industry-standardprotocol, such as FTAM, FTP, or the remote procedure call (RPC, forsending short data messages), and data transmission protocols such asTCP/IP or OSI-WAN, for example.

The present invention is particularly suitable for transferring a seriesof data files from a computer which produces such files in very largenumbers, such as a Formatting and Output Subsystem (FOS), which is apost-processing system that formats data so that it can easily behandled by other post-processing systems, such as a billing center, forexample. An FOS may collect raw charging data from a telephony switch,store the data, and then extract call records from the message store anddecode/encode them. Depending on the input values, data types areselected, formatted, and multicast to post-processing systems, such as anetwork mediator, a billing system, or other business support systems.

FIG. 7 is a diagram showing the data flow in an exemplary computersystem 700 that processes raw charging data comprising an FOS utilizingan output protocol in accordance with a second embodiment of the presentinvention. In computer system 700, raw charging data 702 is received bythe FOS 730 via a high-capacity message transfer protocol AP (MTAP) andis safely stored in safe storage device 720. FOS 730 then may beactivated to process and send formatted charging data by an internalcalendar mechanism (not shown) at predefined intervals, by apost-processing system, a user via a Telnet connection, or otherinitiating procedure. When activated, the raw charging data flows fromthe safe storage device 720 to the decoding, formatting, filtering andencoding device 732 in which call records are extracted and formattedfrom the raw charging data. Device 732 also includes a multicastingcomponent 734 for preparing formatted charging data files formulticasting, one file at a time, to several destination (remote) nodes.While device 732 is shown as a single block and is described as adevice, it is essentially a data processing application, or supportiveof an application of the FOS for providing formatted data files fortransfer to one or more remote node devices. The functionality of device732 may be divided between several software and/or hardwaresubcomponents. Communication line 735 represents a communication pathbetween device 732 and component 734 and a file transfer manager 736, adevice for providing output protocol of the present invention. Forexample, the output protocol device may be the file transfer manager 430of the first exemplary embodiment. File transfer manager 736 has accessalong path 737 to a file store 738 in which the multicast data filesfrom multicasting component 734 are stored. File transfer manager 736has several associated directories in file store 738 and moves files theFOS wishes to transfer according to the processes described above withrespect to FIGS. 5 b-5 g. Files destined for transfer that are outputfrom multicasting component 734 may be created directly in an initialdirectory of the file transfer manager 736, for example, the directoryTmpReady shown in FIG. 5 a. Alternatively, file transfer manager 736 maybe configured to be instructed to move one or more files into the filetransfer manager initial directory as needed by the formattingapplication device 732 and multicasting component 734. Files transferredout of the file store 738 by the file transfer manager 736 may utilizeeither FTP 742, FTAM 744 or other file transfer protocols in the lowerprotocol layer for copying the files to a remote node, the choicedepending on the appropriate protocol needed to transfer a file to theremote node. Also shown output from multicasting component 734 is a pathto the message-based remote procedure call protocol (RPC). RPC is usedin some situations where, instead of collecting several messages in afile, an urgent, short data message must be sent to a post-processingsystem. For example, hot billing may be implemented by using RPC tooutput call records with minimal delay (e.g., less than 10 seconds)through computer system 700. After communicating with the lower protocollayers, the formatted charging data 746 is transferred to a single, ormultiple destinations.

FIG. 8 shows an exemplary layered communication protocol stack 810-840that may be used in the computer system 700 to establish a connectionand safely transfer files and/or messages between the source nodecomputer and a remote node computer. The source node computer utilizesthe protocol architecture 802 and the remote node computer utilizes theprotocol architecture 804, however, the designations source and remotefor architectures 802, 804 may be interchanged depending on whether anode is initiating the file transfer or is on the receiving end the filetransfer. It is to be understood that the layered communication protocolshown in FIG. 8 is for purposes of conceptual understanding of theinvention, and is not intended to show every possible combination ofprotocols. It will be apparent to those skilled in the art that otherprotocol combinations may be used when practicing the invention.

Layers 810-820 comprise the network interface layers of thecommunication protocol stacks of architectures 802, 804, such as thenetwork interface layers 320 described above. Starting with layer 810,it is shown that the source node computer 802 may use a combinationincluding OSI-WAN and Ethernet or X.25 network protocol, or acombination including TCP/IP and Ethernet or X.25 protocol. FTAM, FTP,RPC and TELNET protocols of the layer 820 are shown above correspondingdata transfer protocols of layer 810 to conceptually illustratecommunication between appropriate combinations of message and filetransfer protocols and lower level protocols OSI and TCP/IP of layer810. Protocol layer 830 is a higher level layer that includes a filetransfer manager 736 utilizing safe output protocol, as described above,for transferring files to one or more destinations. Above layer 830 isthe application layer 840 that includes the software application(s)running on the computer. An application in the application layer at thesource node may communicate with the file transfer manager 736 when itdesires to send one or more files to one or more remote node computers.

The lower protocol stack layers 810-820 comprise an industry-standardprocessor platform base that offers wide support for commerciallyavailable computer hardware and software. By using an industry-standardplatform in the present embodiment, benefits gained include steadyincreases in processing power, reductions in the physical size ofcomputer equipment, and favorable cost trends. In addition, new featuresmay be introduced with shorter lead time shortly after they becomeavailable in the computer industry marketplace. Another benefit of usingan industry-standard platform is that network engineers gain astandardized external data interface. For example, data from a networknode is generally transferred to business data systems in a billingcenter or in an operation and maintenance (O&M) center by means of awide area network (WAN) or by some other long-distance datacommunication system. A standardized interface in these mixedenvironments is a welcome feature.

While protocol architectures 802 and 804 are shown in FIG. 8 as havingthe same protocol layers, the remote node computer may need not includeevery protocol combination. Although not shown, protocol architectures802 or 804 may include additional or alternative sets of protocolcombinations, for example, data-link protocols such as Token Ring, ATM,SONET and Frame Relay; session protocols such as simple networkmanagement protocol (SNMP) and control message Internet protocol (CMIP),user datagram protocol (UDP) as a transport protocol; and otherindustry-standard protocols. While the remote node computer protocolstack 804 is shown as including a file transfer manager 736, it does notnecessarily comprise a file transfer manager.

The file transfer protocol described in the foregoing exemplaryembodiments may be used for safely transferring charging information toa billing system or mediator, and also for any other type of data thathas to be safely transferred.

The various aspects of the invention have been described in connectionwith a number of exemplary embodiments. To facilitate an understandingof the invention, many aspects of the invention were described in termsof sequences of actions to be performed by elements of a computersystem. It will be recognized that in each of the embodiments, thevarious actions could be performed by specialized circuits (e.g.,discrete logic gates interconnected to perform a specialized function),by program instructions being executed by one or more processors, or bya combination of both. Moreover, the invention can additionally beconsidered to be embodied entirely within any form of computer readablecarrier, such as solid-state memory, magnetic disk, optical disk orcarrier wave (such as radio frequency, audio frequency or opticalfrequency carrier waves) containing an appropriate set of computerinstructions that would cause a processor to carry out the techniquesdescribed herein. Thus, the various aspects of the invention may beembodied in many different forms, and all such forms are contemplated tobe within the scope of the invention. For each of the various aspects ofthe invention, any such form of embodiments may be referred to herein as“logic configured to” perform a described action, or alternatively as“logic that” performs a described action.

It will be apparent to those skilled in the art that various changes andmodifications can be made in safe output protocol for files to multipledestinations with integrity check of the present invention withoutdeparting from the spirit and scope thereof thus, it is intended thatthe present invention cover the modifications of this invention providedthey come within the scope of the appended claims and their equivalents.

What is claimed is:
 1. A method of transferring one or more electronicfiles between a first system at a first location and at least onereceiving system remote from the first system in a communicationnetwork, comprising: establishing a sending storage area in a memory ofthe first system, the sending storage area including at least onesub-area for storing a file that is to be transferred to a correspondingone of the at least one receiving system; establishing at least onepost-sending storage area in the memory; preparing in the memory atleast one electronic file for transfer to the at least one receivingsystem; requesting the at least one receiving system to create and opena new file name using the file name of the file to be transferred andadding a tmp extension identifying the new file as temporary (tmp);moving the at least one prepared electronic file into one of the atleast one subareas of the sending storage area; transferring the atleast one prepared electronic file to a receive storage area of the atleast one receiving system by way of a copy operation; the first systemmaintaining control over the new file with the tmp extension; receivinga first message from the at least one receiving system indicatingwhether the transfer of the new file with the tmp extension wassuccessful; transferring a second message from the first system to theat least one receiving system when a received first message includes anindication of successful transfer, the second message includinginstructions to remove the tmp extension; and moving the preparedelectronic file from the sending storage area to the at least onepost-sending area when a received first message includes an indicationof successful transfer.
 2. The method according to claim 1, furthercomprising establishing a plurality of sub-areas in the sending storagearea, each of which corresponds to one of a plurality of remote systemsto which one or more electronic files are to be transferred, one by one,from the first system.
 3. The method according to claim 2, wherein theorder that the prepared electronic files stored in the sending storagesub-areas are transferred is the order that the prepared files arecreated.
 4. The method according to claim 1, wherein the at least onepost-sending storage area comprises first and second post-sendingsub-areas and the step of moving the electronic file from the sendingstorage area comprises first moving the electronic file to the firstpost-sending area and thereafter moving the electronic file to thesecond post-sending area during a periodic scan of the first postsending area by the first system.
 5. The method according to claim 4,further comprising deleting files that are stored in the secondpost-sending area after a predetermined period of time has elapsed orduring a condition when a predetermined storage allocation limit of thememory is met or exceeded.
 6. The method according to claim 1, furthercomprising: performing an integrity check on the copied electronic fileby the second system; and generating the first message.
 7. The methodaccording to claim 1, wherein prior to the step of moving the at leastone prepared electronic file into one of the at least one sub-areas ofthe sending storage area, the method further comprises: establishingpre-sending storage areas in the memory, the pre-sending storage areasincluding an initial storage area and a secondary storage area; movingthe prepared electronic file to the initial storage area; and moving theprepared electronic file from the initial storage area to the secondarystorage area after the prepared file is ready for transmission.
 8. Themethod of claim 1, wherein the step of adding the tmp extension includesmodifying or adding the extension to the prepared electronic file, andthe instructions to alter include removing or modifying the extension,after which the at least one receiving system assumes control over thetransmitted file.
 9. A computer using a communication protocol includinga file transfer protocol for transferring data files between thecomputer and at least one other computer in a network, the computercomprising: a memory; a file system for naming, storing, moving, copyingor removing data files residing in a plurality of areas of the memory;at least one application for executing a program generating one or moredata files for transfer to at least one other computer; and a filetransfer manager component for providing overall control of an outgoingtransfer of each of the one or more data files by utilizing an outputprotocol defining a plurality of operations by the file system on aplurality of directories located in the memory and associated with thefile transfer manager component, wherein the file transfer managercomponent, operating in a higher protocol layer of the communicationprotocol than the file transfer protocol, forms an interface between theat least one application program and the file transfer protocol, thefile transfer manager requesting the at least one computer to create andopen a new file name using the file name of the file to be transferredand adding a tmp extension identifying the new file as temporary; theplurality of associated directories comprising: a first directory forstoring the one or more data files as they are being created by the atleast one application for transfer to the at least one other computer; asecond directory for storing the one or more data files, wherein each ofthe data files in the second directory have been moved from the firstdirectory after completing its creation; a third directory for storingthe one or more of the data files moved thereto from the seconddirectory while the file is transferred using the file transferprotocol, wherein the one or more data files are moved from the secondto the third directory only when the computer is ready to transmit theone or more data files to the at least one other computer; and a fourthdirectory for storing ones of the one or more data files that have beenacknowledged as having been successfully transmitted while in the thirddirectory by a first message sent from the receiving one of the othercomputers to the computer.
 10. The computer of claim 9, furthercomprising a fifth directory associated with the file transfer managercomponent.
 11. The computer of claim 10, the file transfer managercomprising a scanning component for periodically detecting the presenceof files in the fourth directory, wherein files detected by the scanningcomponent are moved to the fifth directory and deleted therefrom after apredetermined amount of time or in a condition when a predeterminedmemory allocation amount has been met or exceeded.
 12. The computer ofclaim 9, wherein the third directory comprises a plurality ofsubdirectories, and each subdirectory is associated with a respectiveone of the other computers and storing files being transferred to therespective one of the other computers.
 13. The computer of claim 9,further comprising a sixth directory for receiving the message from theone or more other computers.
 14. The computer of claim 9, wherein theprotocol used by file transfer manager component includes rules foraltering a name of each data file that is transmitted to one or more ofthe other computers to prevent the receiving other computer from acontrol over the transmitted data file and thereby maintain the controlof the file by the computer.
 15. The computer of claim 14, wherein thefile transfer manager component comprises a message generatingcomponent.
 16. The computer of claim 15, wherein the protocol used bythe file transfer manager component includes rules for transmitting asecond message generated by the message generating component to theother computer after receiving the first message from the othercomputer, the second message instructing the other computer to removethe tmp extension and thereby transfer the control of the transmittedfile to the other computer.
 17. The computer of claim 9, wherein each ofthe data files transmitted from the computer includes integrity datacheck bits that are used by the other computer to generate theacknowledgment message.